THE deal . II LIBRARY , VERSION

This paper provides an overview of the new features of the finite element library deal.II version 8.0. 1. Overview. deal.II version 8.0 was released July 24, 2013. This paper provides an overview of the new features of this release and serves as a citable web reference for the deal.II software library version 8.0. deal.II is an object-oriented finite element library used around the world in the development of finite element solvers. It is available for free under the GNU Lesser General Public License (LGPL) from the deal.II homepage at http://www.dealii.org/. Version 8.0 is a major release. It has numerous significant features along with the usual set of bug fixes and documentation updates. In particular, it has the following noteworthy large changes: – The configuration and build system has been switched to CMake, providing better support for a wide variety of platforms, better integration with IDEs such as Eclipse, and many other advantages. See Section 2.1. – deal.II now supports 64-bit integers for degrees of freedom indices for problems with more than 2 billion unknowns and has been tested on problems of up to 27 billion unknowns. See Section 2.2. – deal.II is now licensed under the GNU Lesser General Public License version 2.1 or later (LGPL-2.1+), see Section 2.3 for details. – There is the usual set of dozens or hundreds of new small features and bugfixes, some of which are described in 2.4. Information on how to cite deal.II is provided in Section 3. 2. Important Changes. 2.1. Build System. With the release of version 8.0 and after more than 12 years with an autoconf and custom makefiles setup, deal.II switched its build system over to CMake. This is a major rewrite which changes over 25, 000 lines of code (10,000 insertions and 15,000 deletions) together with a major reorganization and cleanup of ∗Department of Mathematics, Texas A&M University, College Station, TX 77843, USA, [email protected] †Mathematical Sciences, O-110 Martin Hall. Clemson University. Clemson, SC 29634, USA, [email protected] ‡SISSA International School for Advanced Studies, Via Bonomea 265, 34136 Trieste, Italy, [email protected] §Interdisciplinary Center for Scientific Computing, Heidelberg University, Im Neuenheimer Feld 368, 69120 Heidelberg, Germany, [email protected] ¶Institute for Computational Mechanics, Technische Universität München, Boltzmannstr. 15, 85748 Garching b. München, Germany, [email protected] ‖Institute of Applied Mathematics, Heidelberg University, Im Neuenheimer Feld 293/294, 69120 Heidelberg, Germany, [email protected] ∗∗Department of Mathematics, Texas A&M University, College Station, TX 77843, USA, [email protected] ††Institute of Fundamental Technological Research of the Polish Academy of Sciences, ul. Pawińskiego 5b, Warsaw 02-106, Poland, [email protected] 1 ar X iv :1 31 2. 22 66 v3 [ m at h. N A ] 2 8 D ec 2 01 3 the code base. The rewrite addressed quite a number of shortcomings with the old build system, that made a rewrite highly desirable (if not necessary): – Over time, with the addition of an increasing number of external libraries, deal.II can optionally interface with, the configuration happened to be highly heterogeneous—almost every external dependency had to be set up with different command line options with completely different internal setup logic in the autoconf files. – Nowadays, deal.II is used in highly different environments ranging from installations on laptops to computing clusters. The old build system was not suited very well for quite a number of them, e. g. distributional needs or static linkage. – The old build system strongly depended on the availability of a UNIX or GNU/Linux environment due to the fact that GNU Make, Bash and Perl were mandatory build time dependencies, which made support for other platforms (and especially Microsoft Windows) difficult. Arguably, it would have been possible to address all this shortcomings in the current build system, or by changing to another alternative, but there are a number of reasons that make CMake a particularly good choice as build system for deal.II: – CMake readily provides elaborate support for dependency resolution, incremental rebuilds and parallel builds, which were previously implemented mainly by hand. – CMake is a meta build system. It provides support for native toolchains for Linux, BSD, Darwin, and Windows platforms with minimal external dependencies, which drastically increases portability. – CMake supports a variety of commonly used IDEs for different platforms such as Eclipse, KDevelop, Xcode, CodeBlocks or MSVC where it can directly produce a corresponding project. The fact that the new build system was rewritten from scratch, offered the possibility to reformulate and respect some major design criteria. Amongst them are – Full support for all 16 external dependencies in various setups—either compiled and/or installed by the user, or provided by software distributions such as Linux distributions or Mac Ports. – Feature auto detection to ease the setup for the average user, while at the same time providing full user override of configuration options to support almost any setup case. – Be (almost) readily packageable for major distributions (e. g. Debian Linux, or Ubuntu). – Provide a project configuration so that user projects based on deal.II only need a minimalistic CMakeLists.txt file on client side. 2.2. 64-bit Indices. Up to version 7.3 of deal.II, the indices of degrees of freedom (which are uniquely defined) were stored using the unsigned int datatype. This limited the total number of degrees of freedom in a computation to about four billion. When deal.II was used in conjunction with PETSc or Trilinos, this number was in fact only half as large since both of these libraries use signed integer indices (leaving only 31 bits for the indices). Furthermore, because an individual processor needs at least on the order of 10 unknowns to have a suitable amount of work, deal.II could not scale to more than about 2·10 9 105 = 20, 000 processors. Even though this number may seem large, an increasing number of supercomputers offer a much larger number of processors – the fastest supercomputers today are almost one hundred times